Clarify how breaking changes should be handled before 1.0.0
authorIvan Molodetskikh <yalterz@gmail.com>
Mon, 26 Jun 2017 11:05:20 +0000 (14:05 +0300)
committerIvan Molodetskikh <yalterz@gmail.com>
Mon, 26 Jun 2017 11:05:20 +0000 (14:05 +0300)
src/doc/manifest.md

index 4671e36940894a7a09c29e759cd6de65e0e14fec..ff91d8bb77f5bce47166919f27021569e1ffcfc9 100644 (file)
@@ -18,10 +18,11 @@ All three of these fields are mandatory.
 Cargo bakes in the concept of [Semantic
 Versioning](http://semver.org/), so make sure you follow some basic rules:
 
-* Before you reach 1.0.0, anything goes.
+* Before you reach 1.0.0, anything goes, but if you make breaking changes,
+  increment the minor version. In Rust, breaking changes include adding fields to
+  structs or variants to enums.
 * After 1.0.0, only make breaking changes when you increment the major version.
-  In Rust, breaking changes include adding fields to structs or variants to
-  enums. Don’t break the build.
+  Don’t break the build.
 * After 1.0.0, don’t add any new public API (no new `pub` anything) in tiny
   versions. Always increment the minor version if you add any new `pub` structs,
   traits, fields, types, functions, methods or anything else.